home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / maillist / 94-05.Z / 94-05 / 000186_news@bigblue.oit.unc.edu_Tue May 13 17:31:55 1994.msg < prev    next >
Internet Message Format  |  1994-05-31  |  17KB

  1. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AA06926; Fri, 13 May 1994 13:45:14 -0400
  3. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  4.           id AA27631; Fri, 13 May 1994 13:31:42 -0400
  5. Received: from GATEWAY by bigblue with netnews
  6.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  7. To: winsock@sunsite.unc.edu
  8. Date: 13 May 1994 17:31:55 GMT
  9. From: mbc@po.CWRU.Edu (Michael B. Comet)
  10. Message-Id: <2r0dib$pta@usenet.INS.CWRU.Edu>
  11. Organization: Case Western Reserve University, Cleveland, OH (USA)
  12. Sender: ses
  13. References: <2qviju$du0@ratatosk.uninett.no>
  14. Reply-To: mbc@po.CWRU.Edu (Michael B. Comet)
  15. Subject: Re: WSAAsyncSelect(.., FD_WRITE | FD_READ) question!
  16.  
  17.  
  18. In a previous article, spere@kyrre.hsv.no (P. Eivind Jenssen) says:
  19.  
  20. >We are having trouble with FD_READ and FD_WRITE messages!
  21. >We would like to use the function WSAAsyncSelect() this way:
  22. >      WSAAsyncSelect(s, hWnd, READ_OR_WRITE, FD_READ | FD_WRITE);
  23. >
  24. >The READ_OR_WRITE message calls a function of ours.
  25. >Our question is:
  26. >     Can one find out in this function if it was an FD_READ
  27. >     or an FD_WRITE that called the function?
  28. >
  29.  
  30.  
  31.     I don't have the specs in front of me but I think the way it works
  32. is:
  33.  
  34.     Msg will be READ_OR_WRITE
  35.     wParam = socket id
  36.     lParam = LOWORD() = FD_xxxx
  37.          HIWORD() = error code
  38.  
  39.     So LOWORD(lParam) should be FD_READ or FD_WRITE as you need.
  40.  
  41. -- 
  42. +--------------------------------------------------------------------------+
  43. | Michael Comet, mbc@po.CWRU.Edu - CWRU, Software Engineer/Graphics Artist |
  44. | Computer Graphics/Animation! - Liquid Vision SIG (go liquid),  Freenet   |
  45. +--------------------------------------------------------------------------+
  46. From news@bigblue.oit.unc.edu Fri May 13 13:45:18 1994
  47. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  48.           id AA06943; Fri, 13 May 1994 13:45:18 -0400
  49. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  50.           id AA34152; Fri, 13 May 1994 13:44:19 -0400
  51. Received: from GATEWAY by bigblue with netnews
  52.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  53. To: winsock@sunsite.unc.edu
  54. Date: Fri, 13 May 1994 12:56:56
  55. From: overbyte@acy.digex.net (overbyte)
  56. Message-Id: <overbyte.7.000CF34F@acy.digex.net>
  57. Organization: Shakedown Productions
  58. Sender: ses
  59. References: <cpunk.13.000DDDBE@halcyon.com>, <robert.396.00175A62@clark.net>, <Cpq5v5.3HJ@ucdavis.edu>
  60. Subject: Re: is it me or does wintalk stink?
  61.  
  62. In article <Cpq5v5.3HJ@ucdavis.edu> jhframe@ucdavis.edu (Jim Frame) writes:
  63. >From: jhframe@ucdavis.edu (Jim Frame)
  64. >Subject: Re: is it me or does wintalk stink?
  65. >Date: Fri, 13 May 1994 04:59:28 GMT
  66.  
  67. >In article <robert.396.00175A62@clark.net>, robert@clark.net (Robert Seidman) says:
  68. >>It works fine for me, incoming and outgoing.  I'm not sure what your setup
  69. >>is, so I can't offer any advice.  I'm very happy with it...but I do
  70. >>wonder about the icon too! 
  71.  
  72. >I've only used it outgoing, and have but one complaint (aside from the
  73. >obnoxious icon):  the incoming window has no cursor, so I have no 
  74. >indication as to whether or not the other party has paused at the end
  75. >of a line, or issued a couple of returns (I've only used talk with one
  76. >other person, and we "yield the floor" by sending two blank lines).
  77.  
  78. >Once the incoming window is full, I can tell by the fact that the screen
  79. >scrolls upward that a return has been sent; but until that time, I have 
  80. >to resort to guesswork.
  81.  
  82.  I havent had a problem with it. & being its a split screen ansi like chat 
  83. that hold cursor possition i dont worry about typing while the other person 
  84. is... 
  85.  
  86.  
  87.              -The futures here, we are it, we are on our own.
  88.                    Mail via POP Overbyte@acy.digex.net
  89.                           SLIP @lamer.digex.net
  90. From news@bigblue.oit.unc.edu Fri May 13 17:25:55 1994
  91. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  92.           id AA06963; Fri, 13 May 1994 13:45:21 -0400
  93. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  94.           id AA19301; Fri, 13 May 1994 13:43:00 -0400
  95. Received: from GATEWAY by bigblue with netnews
  96.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  97. To: winsock@sunsite.unc.edu
  98. Date: Fri, 13 May 1994 17:25:55 GMT
  99. From: arnstein@netcom.com (David Arnstein)
  100. Message-Id: <arnsteinCpr4F7.HCJ@netcom.com>
  101. Organization: My Own Internet Account!
  102. Sender: ses
  103. References: <1994May12.155317.3383@megatek.com>, <arnsteinCppEAr.L72@netcom.com>, <CppIL6.vK@nntpa.cb.att.com>
  104. Reply-To: arnstein@netcom.com
  105. Subject: Re: 32 bit access with SCSI no available. Hunh? was Re: Win Mosaic alpha 4 (my fix)
  106.  
  107. In article <CppIL6.vK@nntpa.cb.att.com>,
  108. na8520d00-Nichols <rnichols@ihlpm.ih.att.com> wrote:
  109. >In article <arnsteinCppEAr.L72@netcom.com>,
  110. >>Windows 3.1 users:
  111. >>
  112. >>    ***   J U S T    S A Y    N O    T O    S C S I   ***
  113. >
  114. >You keep repeating this litany over and over, perhaps expecting it to
  115. >become true by repetition alone.
  116. >
  117. >Windows can run just fine on SCSI system, and the presence or absence
  118. >of 32-bit access has little effect on the performance.  I run Windows
  119. >on a SCSI system with no performance problems whatsoever.
  120.  
  121. Put your money where your mouth is.  Find yourself a peecee with your
  122. favorite SCSI host adapter and disk drive, and an IDE drive of recent
  123. vintage.  Run WinBench 4.0 to obtain disk timings on each drive.  I
  124. did.  That's how I came to my conclusion:  just say no to SCSI!  I've
  125. corresponded with plenty of folks who say "I'm using SCSI and it
  126. works just fine, thank you."  But if your expensive SCSI hardware
  127. doesn't decisively outperform an IDE disk, you've wasted your time
  128. and money.
  129.  
  130. >If you are accessing your SCSI disk via the SCSI BIOS, though, you may
  131. >indeed have a major performance problem.  For a busmastering SCSI
  132. >adapter, this implies that you are using the double-buffering function
  133. >of SMARTDrive, which will turn the fastest system into a dog.  (This
  134. >was the case on my own system, as the manufacturer configured it.) 
  135. >What you desperately need is an ASPI driver that either (a) supports
  136. >the virtual DMA interface directly, or (b) provides the necessary
  137. >buffering itself.  This will allow you to get rid of the SMARTDRV
  138. >/DOUBLE_BUFFER line in your CONFIG.SYS.  Furthermore, the SCSI BIOS is
  139. >no longer used once the ASPI driver is installed.  This eliminates
  140. >another performance bottleneck since it is often impossible to enable
  141. >shadowing for the SCSI BIOS, forcing the CPU to run directly from the
  142. >8-bit EPROM.  (In busmastering controllers, a portion of this address
  143. >range is used as a mailbox and must be writable.  Most motherboards do
  144. >not allow you to shadow a range of addresses and still be able to
  145. >perform writes there.)
  146.  
  147. I have a Future Domain SCSI host adapter.  It does not do
  148. busmastering, it uses programmed I/O (PIO).  Therefore, I don't need
  149. double buffering.  I don't use it.  If your ASPI driver is a DOS TSR,
  150. it must still run in real mode, so you're still paying the (large)
  151. performance penalty for switching between protected mode and real
  152. mode.  By the way, busmastering SCSI host adapters cause problems
  153. when used with floppy port tape drives (QIC 40 and QIC 80 standard).
  154. This is because of the crappy support for DMA provided by the
  155. industry standard architecture.  If you use such a tape drive, you'll
  156. have to fiddle with the "bus on" time of your SCSI host adapter,
  157. complicating your life and further degrading SCSI I/O speed.
  158.  
  159. Maybe I should ditch my Future Domain h.a. in favor of Adaptec,
  160. apparently that's what you're using.  But Adaptec is expensive, and
  161. the magazine reviews I've seen indicate that the Future Domain 1680
  162. (my h.a.) is a speedy product.
  163.  
  164. >If you cannot obtain a driver that will permit you to eliminate
  165. >SMARTDrive's double buffering, then I would have to agree with your
  166. >"JUST SAY NO" advice -- for that particular SCSI adapter, anyway.
  167. >
  168. >(BTW, to the best of my knowledge, the ASPI drivers in the
  169. >CorelSCSI! package do NOT allow you to eliminate SMARTDrive's double
  170. >buffering.  Adaptec's ASPI4DOS has a switch to provide the necessary
  171. >buffering itself, as do the drivers for DTC's busmastering SCSI
  172. >adapters.  For the Buslogic BT747S, the drivers perform the necessary
  173. >functions automatically, with no explicit switch required.  I have no
  174. >experience with other SCSI adapters.)
  175. -- 
  176. David Arnstein       |          What do you mean, "get a life"?
  177. arnstein@netcom.com  |          This *is* my life!
  178. From news@bigblue.oit.unc.edu Fri May 13 14:15:10 1994
  179. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  180.           id AA13623; Fri, 13 May 1994 14:15:10 -0400
  181. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  182.           id AA34154; Fri, 13 May 1994 13:45:14 -0400
  183. Received: from GATEWAY by bigblue with netnews
  184.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  185. To: winsock@sunsite.unc.edu
  186. Date: Fri, 13 May 1994 12:59:33
  187. From: overbyte@acy.digex.net (overbyte)
  188. Message-Id: <overbyte.8.000CFE75@acy.digex.net>
  189. Organization: Shakedown Productions
  190. Sender: ses
  191. References: <2qv4hk$161f@inca.gate.net>, <2qvtlj$5e5@news.csie.nctu.edu.tw>
  192. Subject: Re: alt.winsock.binaries???
  193.  
  194. In article <2qvtlj$5e5@news.csie.nctu.edu.tw> jenwen@pdd.iii.org.tw (Jenwen) writes:
  195. >From: jenwen@pdd.iii.org.tw (Jenwen)
  196. >Subject: Re: alt.winsock.binaries???
  197. >Date: 13 May 1994 13:00:35 GMT
  198.  
  199. >Nickolas (Nickolas@inca.gate.net) wrote:
  200. >: Hello people,
  201. >: 
  202. >:    I was thinking how  about making a group for binary posting?
  203. >: It would better for some one who wants to release there winsock
  204. >: software. Just a thought ;)
  205. >: 
  206. >:     Nickolas@inca.gate.net
  207.  
  208. >I agree!! Since it seem so many ask where Trumpet? where ..
  209.  
  210. >Jenwen,Chien-Wen Huang
  211. >jenwen@netrd.net.tw 
  212.  
  213.  I secound that! I think a WINSOCK only binary groupe would be great since
  214. most of thew stuff is beta & buggy why mix it up in an enormous news group. 
  215. leave it specialized...
  216.  
  217.              -The futures here, we are it, we are on our own.
  218.                    Mail via POP Overbyte@acy.digex.net
  219.                           SLIP @lamer.digex.net
  220. From news@bigblue.oit.unc.edu Fri May 13 17:30:11 1994
  221. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  222.           id AA13633; Fri, 13 May 1994 14:15:12 -0400
  223. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  224.           id AA12213; Fri, 13 May 1994 13:52:17 -0400
  225. Received: from GATEWAY by bigblue with netnews
  226.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  227. To: winsock@sunsite.unc.edu
  228. Date: Fri, 13 May 1994 17:30:11 GMT
  229. From: arnstein@netcom.com (David Arnstein)
  230. Message-Id: <arnsteinCpr4MC.HL5@netcom.com>
  231. Organization: My Own Internet Account!
  232. Sender: ses
  233. References: <arnsteinCppEAr.L72@netcom.com>, <CppIL6.vK@nntpa.cb.att.com>, <2quet0$8u3@bmerha64.bnr.ca>
  234. Reply-To: arnstein@netcom.com
  235. Subject: Re: 32 bit access with SCSI not avail. -> Adaptec questions.
  236.  
  237. In article <2quet0$8u3@bmerha64.bnr.ca>, Jeff Hayes <jjhayes@bnr.ca> wrote:
  238. >
  239. >_]What you desperately need is an ASPI driver that either (a) supports
  240. >_]the virtual DMA interface directly, or (b) provides the necessary
  241. >_]buffering itself.  This will allow you to get rid of the SMARTDRV
  242. >_]/DOUBLE_BUFFER line in your CONFIG.SYS. 
  243. >    Adaptec docs say to remove the /DOUBLE_BUFFER, set VirtualHDIRQ=off
  244. >in system.ini to make everything happy in Windows.
  245. >
  246. >_]Adaptec's ASPI4DOS has a switch to provide the necessary
  247. >_]buffering itself
  248. >    I have the Adaptec docs here in front of me and there is no
  249. >switch to enable buffering in aspi4dos.  Neither do any of the other 3
  250. >drivers.  Hummm.
  251. >
  252. >    So...
  253. >
  254. >    The questions to answer (Adaptec's docs do not) are:
  255. >
  256. >    Do the Adaptec drivers support VDMA?
  257. >    Do they do there own buffering?
  258. >    Is there buffering cache on the ctlr board?
  259.  
  260. Just listen to all this complexity!  If you have the guts, do a
  261. quantitative comparison of speed of your SCSI nightmare with an IDE
  262. drive - while running Windows 3.1.  Have you gained any speed?
  263. -- 
  264. David Arnstein       |          What do you mean, "get a life"?
  265. arnstein@netcom.com  |          This *is* my life!
  266. From news@bigblue.oit.unc.edu Fri May 13 15:27:41 1994
  267. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  268.           id AA13648; Fri, 13 May 1994 14:15:15 -0400
  269. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  270.           id AA19019; Fri, 13 May 1994 14:12:14 -0400
  271. Received: from GATEWAY by bigblue with netnews
  272.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  273. To: winsock@sunsite.unc.edu
  274. Date: Fri, 13 May 94 15:27:41 GMT
  275. From: cbarton@clark.dgim.doc.ca (Casey Barton)
  276. Message-Id: <cbarton.115.2DD39C6A@clark.dgim.doc.ca>
  277. Organization: None
  278. Sender: ses
  279. References: <toreh.24.2DC76C31@bootes.sds.no>, <jones.35.0017A7E6@cbdb1.nimh.nih.gov>, <toreh.1.2DD37539@bootes.sds.no>
  280. Subject: Re: The purpose of this news group: netsurfing?
  281.  
  282. toreh@bootes.sds.no (Tore Haraldsen) writes:
  283. >Well, since this news group started out as a continuation of the 
  284. >corresponding winsock mailing-list, I do not think my question was 
  285. >impertinent. This group WAS alt.winsock.programming!
  286.  
  287.     Well, it underwent a spontaneous name change then. It now seems to be 
  288. called alt.winsock.
  289.  
  290. >This group WAS supposed to be the forum for specialized questions around 
  291. >winsock programming.
  292.  
  293.     Regardless of initial intentions, this group is now fulfilling a useful 
  294. niche -- winsock applications are probably the single fastest growing group of 
  295. internet access software around, and a common forum for discussion is useful. 
  296. In fact, I believe that a comp.*.winsock would be fully justified...
  297.  
  298.     A group specifically for winsock *programming* should, logically, be 
  299. called *.winsock.programming, no?  There's certainly a demand for it. Why 
  300. don't you initiate the process of creating it, instead of stating that nearly
  301. everybody that is making good use of this group should be somewhere else?
  302.  
  303. >What I was trying to say (and maybe I did not make it clear enough), is the 
  304. >obvious lack of a news group for connectivity & utilities discussions. This 
  305. >group is not the only one , others being comp.protocol.nfs, 
  306. >comp.protocol.tcpip.* etc.
  307. >
  308. >So I tried to suggest  we need a specialized group for connectivity & 
  309. >utilities: alt.winsurf or alt.netsurf may be.
  310.  
  311.     But the bulk of non-programming-related posts here are not simply generic 
  312. "netsurfing" questions -- they are *winsock* specific. So they certainly have 
  313. a place here.  Perhaps a generic "netsurf" group would be useful as well, 
  314. though I suspect that alt.netsurf is a little too generic. At any rate, any 
  315. such group should be created in *addition* to this group, not in place of it.
  316. +-----------------------------------------------------------------------------+
  317. |          Casey Barton (a guy)            cbarton@clark.dgim.doc.ca          |
  318. |              http://pctcp132.dgcp.doc.ca/personal/index.html                |
  319. From news@bigblue.oit.unc.edu Fri May 13 16:30:03 1994
  320. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  321.           id AA21702; Fri, 13 May 1994 14:45:10 -0400
  322. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  323.           id AA23923; Fri, 13 May 1994 14:21:02 -0400
  324. Received: from GATEWAY by bigblue with netnews
  325.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  326. To: winsock@sunsite.unc.edu
  327. Date: Fri, 13 May 1994 16:30:03 GMT
  328. From: cpm@uplx.co.uk (Chris P Murray)
  329. Message-Id: <Cpr1u5.6pI@uniplex.co.uk>
  330. Organization: Uniplex Ltd.
  331. Sender: ses
  332. References: <2qtem9$il3@debbie.cc.nctu.edu.tw>
  333. Subject: Re: Why connect error?
  334.  
  335. u8234514@cc.nctu.edu.tw wrote:
  336. :  sockfd = socket(AF_INET, SOCK_STREAM, 0)
  337. :  If (sockfd <= 0) Then
  338. :     MsgBox ("Open socket error!")
  339. :  End If
  340. :  dest.sin_family = AF_INET
  341. :  dest.sin_addr = inet_addr(txtHost.Text)
  342. :  dest.sin_port = htons(Val(txtPort.Text))
  343. :  destlen = 15
  344. :  If (connect(sockfd, dest, destlen) < 0) Then
  345. :     MsgBox ("Connect Error")
  346. :  End If
  347.  
  348. I'm assuming 'dest' is correctly defined as:
  349.  
  350.     struct sockaddr_in dest;
  351.  
  352. then try:
  353.  
  354.   sockfd = socket(AF_INET, SOCK_STREAM, 0)
  355.   If (sockfd < 0) Then
  356.      MsgBox ("Open socket error!")
  357.   End If
  358.   bzero((char *) &dest, sizeof(dest));
  359.   dest.sin_family = AF_INET
  360.   dest.sin_addr = inet_addr(txtHost.Text)
  361.   dest.sin_port = htons(Val(txtPort.Text))
  362.   If (connect(sockfd, (struct sockaddr *) &dest, sizeof(dest)) < 0) Then
  363.     MsgBox ("Connect Error")
  364.  
  365. (Note the 'If (sockfd < 0)' test should be '< 0' not '<= 0' as it could
  366.  return fd 0 is you've close stdin)
  367.